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(54) System and method for dynamically loading platform independent drivers 



(57) A system and method is disclosed for dynami- 
cally loading platform independent drivers. The inven- 
tion encompasses a "Printlet" and a "Printlet Dock Print 
Driver." collectively referred to as the Printlet System. A 
Printlet is that portion of the present invention compris- 
ing platform-independent software technology (such as 
Java) and, generally, is software which enables a com- 
puter system or a network of electronically connected 
computers to communicate with a specific device (in the 
same manner as a device driver). The Printlet is dynam- 
ically loaded from the connected device by the operat- 
ing system of a computer upon invocation by the user, 
or a client application,; or on demand. The platform 
independent Printlet interfaces with a Printlet Dock 
Device Driver. A Printlet Dock Print Driver (PDPD) is 
built into, or installed upon, the OS; is computer system 
platform and device independent and implements, or 
otherwise activates, a defined PrintletManager's API 
and it preferably provides a graphical user interface 
(GUI) to enable the user to select a Printlet-Enabled 
device. The PDPD loads the Printlet from the Printlet 
Enabled device and, subsequently, activates the Printlet 
software to thereafter place the computer system in 
communication with that device. Various embodiments 
include, but are not limited to the addition of: a Down- 
load Manager which implements various download pro- 
tocols and manages a local cached; a multiplicity of 
GUI's to provide the user with the capability to manage 
a plurality of devices, job ticket controls, display device 



status, and administrative support; ability to detect 
Printlet-Enabled devices and add them to a device list; 
and the ability to add device specific rendering and PDL 
generation, if desired. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to the field of 
operating systems and device driver technology and 
architectures and, more particularly, to systems and 
methods for loading device drivers into a computer sys- 
tem or network. 

BACKGROUND OF THE INVENTION 

[0002] In the arts, when an operating system (OS) 
boots up it is typical for the OS to seek out and load into 
memory all the device driven which it needs to activate 
various process devices attached to the computer sys- 
tem, such as, printer drivers. With respect to printing 
devices, when the computer operator wishes to send a 
page to the printer for processing the operating system 
invokes the specific driver for that printing device to 
process the page. If there is a printing device con- 
nected to the computer system for which the operating 
system does not have the driver already loaded, then 
the operator will get an error message sent back from 
the operating system indicating that the device driver 
does not exist. 

[0003] On every client platform (computer), one or 
more print drivers are pre-installed in the platform oper- 
ating system. Each print driver is designed to interface 
with a particular kind of printer using that printer's exter- 
nal interface. Furthermore, the print driver is targeted to 
the specific operating system; it uses that operating sys- 
tem's standard print driver application programming 
interface (API) to communicate with the operating sys- 
tem. The operating system often provides a common 
print user interface (Ul), typically invoked by an applica- 
tion's "Print" and "Page Setup" commands. On many 
OS's the print driver can also supply a custom print Ul 
for its associated printer that allows the user to control 
printer features beyond those provided in common print 
Ul. 

[0004] When a client application wants to do a print 
job, the client application uses the operating system's 
standard client print API to choose one of the installed 
printers and generate the printout. The operating sys- 
tem in turn communicates with the chosen print driver, 
translating the standard client print API calls into stand- 
ard print driver API calls. The print driver in turn commu- 
nicates with its associated printer to accomplish the 
printout. Note that all the software in this scenario is 
statically loaded, that is, installed in the operating sys- 
tem before any printing takes place. 
[0005] With respect to prior art Figure 1 illustrating 
convention print client software architecture, the client 
platform 1 is the configuration of the specific computer 
being operated by the user, the OS is loaded onto the 
platform and performs major operations for the compu- 
ter system. The standard print driver application pro- 



gram interface (API) 2 is a part of the OS and interfaces 
with the standard print drivers 3 and 4 which, in turn, are 
in communication with the printers through their individ- 
ual printer interfaces 9 and 10. The standard client print 

5 API interfaces 5 and 6 with the client's application soft- 
ware program 13. The client's application program can 
be a word processing program which invokes this inter- 
face 11 and 12 when the user hits the print button. 
Direct interaction with a common print user interface 

70 which can be spawned by either the operating system or 
one of the standard printer drivers is often required. 
Through this interface, the printer's specific configura- 
tion, i.e., page size, fonts, etc, are entered by the user 
along with any other printer specific instructions either 

75 mandated or optionally required. 

[0006] Although there are several advantages with 
the above described architecture because the operating 
system merely provides the infrastructure for installing 
and invoking print driver modules and interfacing with 

20 the client's application, the printer interface drivers are 
not built into the operating system and have to be pre- 
loaded prior to accessing (or sending jobs to) the 
device. This requires specific knowledge about the con- 
nected printing device, which may not always be the 

25 case, and the availability of the driver interface pro- 
grams. In order for the client's application to be able to 
make use of a particular printing device, the client must 
first pre-install that particular printer's print driver. This 
consumes client resources and, quite often, the printer's 

30 drivers are either difficult to find or are out of date. In this 
respect, the user cannot readily use arbitrarily con- 
nected printing devices on-the-fly without some pre- 
existing knowledge of the priming device and without 
the driver already having been loaded by the OS. 

35 [0007] Currently, print drivers need to be targeted to 
a specific OS. Since a print driver is targeted to a spe- 
cific OS, the same printer needs different print drivers 
designed and coded for differing operating systems. In 
other words, a printer vendor must spend considerable 

40 resources in the design and development of separate 
print drivers for each combination of a printer and an 
OS. If the vendor sells M printers and supports N oper- 
ating systems, the vendor must develop M*N print driv- 
ers which increases product development expense and 

45 the cost of the end product increases as well. 

[0008] The print driver's custom print user-interface 
(Ul) typically employs the target operating system's Ul 
look and feel conventions which may vary widely across 
a plurality of computer platforms. As a result, the same 

so printer typically has to have multiple custom print Uls 
designed and coded for a plurality of different operating 
systems. Thus, to use the same printer from different cli- 
ent platforms, the user must not only have the correct 
driver to install, but must also learn to use multiple cus- 

55 torn print Uls. 

[0009] Software administration of a plurality of driv- 
ers over a network can be cumbersome. If a printer's 
embedded software needs to change in order to fix 



2 



3 



EP 1 056 001 A2 



4 



defects or add new capabilities then the corresponding 
print driver software may also change. This has the 
drawback of having to distribute to all current users the 
new print drivers and having the end-users install the 
new print driver on potentially a large number of client 5 
workstations. 

SUMMARY OF THE INVENTION 

[0010] A system and method providing for dynami- 10 
cally loading platform independent drivers encompass- 
ing a "Printlef and a "Printlet Dock Print Driver." 
collectively referred to as the Printlet System. A Printlet 
is that portion of the present invention comprising plat- 
form-independent software technology (such as Java) is 
and, generally, is software which enables a computer 
system or a network of electronically connected com- 
puters to communicate with a specific device (in the 
same manner as a device driver). The Printlet is dynam- 
ically loaded from the connected device by the operat- 20 
ing system of a computer upon invocation by the user, 
or a client application,; or on demand. The platform 
independent Printlet interfaces with a Printlet Dock 
Device Driver. A Printlet Dock Print Driver (PDPD) is 
built into, or installed upon, the OS; is computer system 25 
platform and device independent and implements, or 
otherwise activates, a defined Printlet Manager's API 
and it preferably provides a graphical user interface 
(GUI) to enable the user to select a Printlet- Enabled 
device. The PDPD loads the Printlet from the Printlet 30 
Enabled device and, subsequently, activates the Printlet 
software to thereafter place the computer system in 
communication with that device. Various embodiments 
include, but are not limited to the addition of: a Down- 
load Manager which implements various download pro- 35 
tocols and manages a local cached; a multiplicity of 
GUI's to provide the user with the capability to manage 
a plurality of devices, job ticket controls, display device 
status, and administrative support; ability to detect 
Printlet-Enabled devices and add them to a device list; 40 
and the ability to add device specific rendering and PDL 
generation, if desired. 

[0011] Additional benefits and advantages of the 
present invention will be set forth in the description 
which follows, and in part will be obvious from the 45 
description, or may be learned by the practice of this 
invention. The advantages of this invention, as 
described herein, may be realized and obtained by 
means particularly pointed out and distinctly claimed in 
the appended claims, taken in conjunction with the so 
accompanying drawings and detailed specification. 

BRIEF DESCRIPTION OF THE DRAWINGS: 

[0012] In order that the manner in which the above- 55 
recited and other advantages and objects of the present 
invention are obtained, a more particular description of 
this invention, briefly described above, will be rendered 



by reference to a specific embodiment thereof which is 
illustrated in the appended drawings. Understanding 
that these drawings depict only a typical embodiment of 
the present invention and are not therefore to be consid- 
ered in any way limiting of its scope, this invention will 
be described and explained with additional specificity 
and detail through the use of the accompanying draw- 
ings, in which: 

Figure 1 is a prior art illustration of conventional 
print client software architecture; 
Figure 2 illustrates the relationship between the 
Platform Dependent Printlet Dock Print Driver and 
the Platform Independent Printlet System; 
Figure 3 illustrates the three layers into which the 
Printlet System of Figure 2A can be divided; 
Figure 4 shows how the Printlet System's architec- 
tural layers are implemented in the Windows-type 
environment; 

Figure 5 shows the Printlet System of the present 
invention configured with the initial capabilities; 

DETAILED DESCRIPTION OF THE SPECIFICATION 

[0013] What is presented is a novel system and 
method for a print client software architecture which, in 
the preferred embodiment, consists of two parts, a 
"Printlef and a "Printlet Dock Print Driver." The system 
and method of the present invention for dynamically 
loading platform independent drivers encompassing the 
above two part is collectively referred to herein as the 
Printlet System. 

[0014] A Printlet, as used herein, refers to that por- 
tion of the software architecture of the present invention 
that enables a computer system or a network of elec- 
tronically connected computers to communicate with 
the device. For example, a printer connected to a com- 
puter system or network would require a printer driver in 
order for the computer system to send print jobs to the 
printer, as more fully describe below. Preferably, the 
Printlet comprises platform-independent software tech- 
nology (such as Java). The Printlet is dynamically 
loaded from the connected device by the operating sys- 
tem of a computer upon invocation by the user, or a cli- 
ent application,; or on demand. The platform 
independent Printlet interfaces with the Printlet Dock 
Device Driver, described herein. 
[0015] A Printlet Dock Print Driver (PDPD), as used 
herein, refers to the portion of the software architecture 
of the present invention resides with the computer sys- 
tem and interfaces with the particular operating system 
(OS) of the computer. It should be understood that 
although the preferred embodiment refers to a Printlet 
Dock Printer Driver (for communicating with printing 
devices), it is intended to also refer, generically, to a 
Printlet Dock Device Driver (PDDD) as well (for commu- 
nicating with any Printlet-Enabled device). Preferably, 
the PDPD is built into, or installed upon, the OS; is com- 
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puter system platform and device independent and 
implements, or otherwise activates, a defined Printlet- 
Manager's API. It may use a lookup service to find avail- 
able Printlet-Enabled printers connected to the 
computer system and it preferably provides a graphical 5 
user interface (GUI) to enable the user to select an 
available Printlet-Enabled device on the computer sys- 
tem. The PDPD or PDDD loads the Printlet from the 
Printlet Enabled device and, subsequently, activates the 
Printlet software to thereafter place the computer sys- to 
tern in communication with that device. 
[0016] An object, as used herein, refers to a soft- 
ware or hardware implementation of the designated 
component. For an example, a CustomPrintUI object 
would refer to a software implementation of a custom- 15 
ized user interface which would allow the user to manip- 
ulate various device settings. In a Windows 
environment, one skilled in the art would be able to gen- 
erate such an object, configure it, and implement it with 
their specific architecture and/or operating system. 20 
[0017] Attention is now directed to the embodiment 
of Figure 2, which illustrates the relationship between a 
Platform Dependent Printlet Dock Print Driver 14 and a 
Platform Independent Printlet 15 in the Printlet System 

1 6 of the present invention 25 
[0018] With reference to Figure 3, the Printlet Sys- 
tem 16 of the present invention preferably comprises 
three layers. The Printlet Dock Print Driver Layer 17 
implements the platform operating system's PrintDriver 
interface by making use of the objects in the subsequent 30 
layers below thereby providing an entry point into the 
Printlet System from the OS. The PDPD layer 1 7 allows 

a client's application, in one embodiment, to print on 
Printlet-Enabled printers transparently. The PDPD layer 

17 is preferably written in a platform specific language 35 
(such as C++) and thereafter installed on the desig- 
nated platform. The Printlet Management Layer 18 
allows the PDPD Layer 1 7 to manage and gain access 

to individual devices' capabilities. The Printlet Manage- 
ment Layer is also preferably written in Java-(a platform 40 
independent language) and then installed on the plat- 
form. In this instance, the Printlet Management Layer's 
Java code would run on a Java Virtual Machine (VM) 19 
environment enabled by the operating system. By 
accessing the Printlets loadable objects from the Print- 45 
let-Enabled device, the Printlet Layer 20 provides 
access to individual devices' capabilities. Each Printlet- 
Enabled device's capabilities may be divided among 
several Printlet objects 22. The Printlet objects' Java 
code would then run in the same Java VM environment 50 
as does the Printlet Management Layer. The combina- 
tion of the top two layers 17 and 1 8 is referred to as the 
Printlet Dock Driver 21. Unlike the dynamically loaded 
Printlet Layer 20, the PDPD Layer 17 is installed in the 
OS like any other driver interfacing software, and the 55 
Printlet Management Layer 18 is installed in whatever 
platform specific manner is needed for the PDPD Layer 
to access the Printlet Management Layer. 



[0019] Figure 4 illustrates how the present inven- 
tion's architectural layers are implemented in a Win- 
dows-type environment. In this implementation, a 
Printlet System Interface 23 class is written as a Java- 
Bean and is packaged in a Java archive (JAR) file. 
When activated, the PDPD Layer first creates a COM 
object instance. The COM object is an instance of the 
ActiveX-JavaBean bridge 24 (such as beans.ocx), 
which contains the Java VM 19. The COM object could 
be run either in-process, i.e., in the PDPD's address 
space, or out-of-process, i.e., in its own separate space. 
In the latter case, there would have to be a server appli- 
cation (an executable) for beans.ocx to run in. The 
ActiveX-JavaBean bridge 24 is given the JAR file and is 
subsequently instructed to create an instance of the 
Printlet Interface class. The bridge creates that object 
and returns an IDispatch interface to it. The PDPD 
Layer 17 then uses the IDispatch interface to invoke on 
or more methods in the Printlet System Interface object 
to gain access to the Java objects in the other layers. 
These objects are returned as IDispatch interface 
instances. 

[0020] Figure 5 illustrates the individual objects of 
the Printlet's architecture of Figs. 2 and 3 and how these 
objects interrelate. In the preferred embodiment, the 
objects of the Printlet of the present invention are also 
implemented as Java objects. Some pieces (or objects) 
are downloadable and their implementations differ from 
device to device (printer to printer). Although the Printlet 
System of the present invention is primarily described 
herein in terms of enabling priming capabilities, the con- 
cepts disclosed herein and architecture thereof are 
equally applicable to other kinds of networked devices 
such as digital copiers, scanners, fax machines, and 
even multifunction devices. Therefore, in the preferred 
embodiment certain objects generically refer to devices 
rather than "printers" as does the alternative embodi- 
ment. Such objects are intended herein to be extenda- 
ble so as to encompass a plurality of other kinds of 
devices. 

[0021] The following description is put forth incre- 
mentally, not only to show step-wise how the preferred 
embodiment (and the alternative embodiment) are 
implemented herein, but also, to illustrate that the 
present invention finds its implementations with a vari- 
ety of readily extendable capabilities as illustrated and 
described. 

[0022] Attention is now directed to Figure 5, which 
shows the Printlet System of the present invention 
implemented. In this specific configuration, the PDPD 
30 interfaces directly to a plurality of objects, the 
DeviceList 31, SelectedDevice 32, SelectedPrinter 33, 
and the JobTicket object 34. The DeviceList 31 object is 
a list of Printlet-Enabled devices available to or other- 
wise selectable by a user which preferably enables the 
following capabilities: (a) gets a default device, if one 
has not been selected, and returns a SelectedDevice 
object; (b) displays a user interface (Ul) allowing the 
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user to pick a device; and returns a SelectedDevice 
object set to the device the user chose; (c) serializes 
device information 35 (in a table or list format) and 
stores the present list's state in persistent storage (such 
as a file); and (d) restores the present list's state from 
persistent storage (de-serializing or reformatting the 
data if needed). For example, a standalone printer's 
would be represented as a device with just a printer 
object. A standalone scanner would be represented as 
a device with just a scanner object. A multifunction 
device would be represented collectively as a device 
with a printer object, a scanner object, and a fax object; 
and so on. In turn, the SelectedDevice object pulls a 
device from the DeviceList object and then delegates 
each desire operation to the actual physical device. 
[0023] In much the same manner as the Selected- 
Device object describe above, the Selected Printer 
object delegates each operation to a selected actual 
Printer 36 connected to the system. In this instance, the 
SelectedPrinter object would perhaps hide from the 
PDPD the fact that invoking certain operations on the 
selected Printer, such as the "get user specified job 
ticket" operation, may actually have the effect of causing 
a different printer to become selected. The same 
SelectedPrinter object also would preferably act as a 
proxy for different actual Printers as the user selects 
them. The printing device then, in turn, receives a 
Job-Ticket object 34 encapsulating knowledge of which 
job template attributes and values a specific printer sup- 
ports and perhaps storing the chosen value for each job 
template attribute. Each Printer instance then would 
have a Job-Ticket object holding the default settings for 
jobs on that printer. For interfacing with the PDPD, the 
system preferably supports transferring job settings into 
and out of the Job-Ticket object as XML-encoded strings 
rather than via a plethora of individual job template 
attribute methods. 

[0024] The printing device preferably also interfaces 
with a JobTicketUI object 37 which encapsulates a Cus- 
tomJobTicketUI for a specific printing device and, when 
displayed, this Ul is furnished the individual JobTicket 
object that specifies the displayed settings. The user's 
inputs are then preferably recorded in the JobTicket 
object that is returned so as to inform the caller what the 
new settings are. The JobTicketUI object is also prefer- 
ably able to request invocation of the DeviceListUI 
object so as to enable the selection of a different device. 
[0025] Lastly, the printing device has knowledge of 
the DeviceStatus object 38 which has the capability of 
discovering a device's status in real time and perhaps 
displaying or otherwise acquiring an icon (or a textual 
description) representing the device's status for presen- 
tation to the user. Preferably, the DeviceStatus object 
also embodies one or more pictorial representations of 
the particular device, for example, a big red X would be 
displayed if there was a problem. 
[0026] The configuration of Figure 5 provides only 
job settings control via the JobTicketTUI object. The 



PDPD uses the platform native Renderer and uses the 
platform native print job submission mechanism. Print- 
ers in this configuration may support various kinds of 
Renderers, such as java.awt.Graphics2D to PostScript, 

5 java.awt.Graphics2D to a proprietary bitmapped format, 
Unicode text to a proprietary byte stream format, and so 
on. It should be understood that in this embodiment, no 
Java classes are downloaded dynamically and no Print- 
let- Enabled device discovery capability is provided. 

10 [0027] The Printlet Manager might alternatively be a 
single component downloaded all at once, or multiple 
components downloaded separately. For example, the 
PrintletManager might consist of multiple components 
for Printlet downloading, Printlet security checking, 

15 Printlet installation, PrintJob management, shared 
printer-independent functions, etc. A particular printer's 
Printlet might alternatively be a single component down- 
loaded all at once, or multiple components downloaded 
separately. For example, the Printlet might consist of 

20 multiple components for one or more Cus- 
tomPrinterUI's, printout rendering, printer management, 
etc. Also, reusable software components may reside in 
any part of the architecture of the present invention. For 
example, a printout rendering software component 

25 (such as a component that converts platform native 
graphics directives to PostScript) might reside in the 
Printlet, or might reside in the PrintletManager, or might 
reside in the PDPD. In the latter two cases, all Printlets 
would preferably share the printout rendering software 

30 component via the Printlet API. The PrintletManager 
and/or the Printlets could alternatively reside in and be 
downloaded from a file server, an HTTP webserver, a 
Jini lookup server, etc. 

[0028] In summary, the present invention provides 
35 all the same benefits as the conventional print client 
software architecture. For instance, printer interface 
code does not have to be built into the operating sys- 
tem; instead, it is built into the aggregation of the PDPD, 
PrintletManager, and Printlets. Client application pro- 
40 grams are insulated from the details of interfacing with 
particular printers. The client applications all use the 
same standard client print API, and the operating sys- 
tem in conjunction with the PDPD, the PrintletManager, 
and the selected Printlet takes care of actually interfac- 
45 ing with the printer. And, CustomPrintUls are easily sup- 
ported. 

[0029] In order to be able to use a particular printer 
in the conventional prior art architecture, the user must 
first manually install that printer's PrintDriver. In the 

50 Printlet architecture of the present invention, the system 
automatically locates and downloads the requisite Print- 
let and the user can use arbitrary printers "on the fly." In 
order to be able to use more than one kind of printer in 
the conventional architecture, the user must pre-install 

55 more than one PrintDriver. In the Printlet architecture of 
the present invention, the user only has to install (or 
interface with) a single PDPD. The system automatically 
locates and downloads the proper Printlets from muiti- 
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pie kinds of printers. Further, since the PrintletManager 
and Printlets are platform independent, the Cus- 
tom PrintU I may conveniently employ platform inde- 
pendent GUI look and feel conventions. Thus, a printer 
may have the same GUI on all operating systems. Thus, 5 
to use the same printer from different client platforms, 
the user must only learn to use a single custom GUI. 
And, since the PDPD is platform dependent but printer 
independent, a vendor that presently sells M printers 
and supports N operating systems need only develop 1 o 
M+N separate modules (i.e., M Printlets and N PDPDs), 
not M'N separate drivers thereby decreasing product 
development expense. Lastly, software administration is 
made much easier by the present invention. For exam- 
ple, a printer's embedded software can be changed 75 
without having to change any client workstation soft- 
ware. The Printlet that resides in the printer is updated 
at the same time as the printer's embedded software. 
The platform's PDPD then automatically downloads the 
new Printlet the next time a client application sends a 20 
job to that device. 

[0030] In addition to the above, the Printlet Software 
Architecture of the present invention provides these 
additional benefits. For instance, a suite of platform- 
independent reusable software components, including 25 
widgets, dialogs, etc., GUI, components for generating 
page description language output (such as PostScript), 
and other components can be made more readily avail- 
able because product development teams can reuse 
these components to develop Printlets rather than build 30 
Printlets entirely from scratch thereby decreasing prod- 
uct development expense and achieving GUI coher- 
ence. The Printlet software architecture supports 
greatly extended printing functionality beyond what typ- 
ical drivers provide. The PrintletManager/Printlet combi- 35 
nation is essentially a full-fledged application program 
that not only can print a document but can also display 
printer status, display print job status, perform print job 
control, and so on. Not being tied to the standard GUI 
convention of any one platform, the PrintletManager's 40 
and Printlet's CustomPrintUI object can be designed for 
the greatest possible ease of use. As already men- 
tioned, by employing platform-independent technology, 
the GUI will be the same on all platforms, thus users 
wont have to learn different GUIs on different platforms. 45 
Printers could be configured more flexibly (more often; 
more variances) because configuration can be done, for 
each printer without need for additional client worksta- 
tion administration. The present invention allows printer 
vendors to stop writing drivers and, eventually, operat- so 
ing system vendors will write the PDPDs for their own 
configurations in accordance with the system and 
method put forth. By implementing to the same defined 
APIs, PDPDs and Printlets will work properly together 
even if developed by different organizations. Lastly, Ven- 55 
dors can implement PrintletManagers with all sorts of 
value-added features, some of which were suggested 
above. Since the PrintletManager is platform independ- 



ent, a new PrintletManager will run on all platforms that 
have a PDPD, thus increasing the potential market size 
for PrintletManagers. By implementing to the same 
defined APIs, PDPDs, PrintletManagers, and Printlets 
will work seamlessly together even if developed by dif- 
ferent organizations. 

[0031] With the above-described detailed descrip- 
tion of the preferred embodiment (and the alternative 
embodiment) of the present invention and the above- 
described variations thereto, one skilled in the art of 
computer architecture and programming will readily find 
their specific implementation in accordance herewith. 
[0032] This invention may be embodied in other 
specific forms without departing from its spirit or essen- 
tial characteristics. The above-described embodiments 
are to be considered in all respects only as illustrative 
and not restrictive in scope. The scope of the invention 
is, therefore, indicated by the appended claims rather 
than by the above-detailed description. Therefore, all 
changes which come within the meaning and range of 
equivalency of the claims are to be considered 
embraced within their scope. 

Claims 

1 . A system for placing a computer operating system 
in communication with a device connected thereto, 
comprising: 

(a) a device driver means embedded in said 
device which enables communication with said 
device; and 

(b) a device driver docking means installed 
upon said operating system for dynamically 
uploading said device driver means as a prel- 
ude to establishing communication with said 
device. 

2. A method for placing a computer operating system 
in communication with a device connected thereto, 
comprising the steps of: 

(a) activating a device driver docking means 
installed upon said operating system; 

(b) uploading a device driver means from said 
device to said operating system; and 

(c) activating said device driver means as a 
prelude to activating said device. 

3. A printlet system for placing a computer operating 
system in communication with a device connected 
thereto, comprising: 

a PrintDockDriver (PDPD) interfacing directly 
with a plurality of actual physical devices; 
a Device ListObject comprising a list of devices 
and which displays said list to a user, allowing 
the user to pick a SelectedDevice and which 
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returns information about said Selected Device 
to said PDPD; 

a SelectedDeviceObject residing in said PDPD 
which delegates each operation to said 
SelectedDevice; and 

a JobTicketObject received by said Selected- 
Device encapsulating knowledge of job tem- 
plate attributes said SelectedDevice supports. 
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